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DESCRIPTION 

SYSTEM AND METHOD FOR NEGOTIATION OF WLAN ENTITY 

5 TECHNICAL FIELD 
[0001] 

The present invention relates to the field of 
wireless local area networks and in particular to the 
operation of such networks in heterogeneous environments. 

10 

BACKGROUND ART 
[0002] • 

Wireless local area networks (WLANs) have invoked 
great interests from both consumers and the industry. 

15 The current most popular WLANs are based on the [Non 
Patent Document 1] standards. While these standards have 
helped the initial uptake of WLANs f in their current 
form, they are not suited for large-scale wireless 
network deployments. This is because the cost and 

20 control of WLAN entities become complex in large 
environments . 
[0003] 

Currently, many WLAN equipment manufacturers have 
addressed large-scale deployments by introducing new 
25 split architecture. Here, control aspects of the [Non 



Patent Document 1] WLAN specifications are centralized 
at controller nodes (CNs) while other aspects are 
distributed to numerous wireless access points (WAPs) . 
With the diversity of manufacturers and their 
5 implementations of the split architecture, there are 
incompatibilities between WLAN entities from different 
manufacturers - 
[0004] 

There are currently some efforts to provide 
10 standardized means for managing large-scale WLANs in the 
Internet Engineering Task Forces (IETF) Control and 
Provisioning of Wireless Access Point (CAPWAP) working 
group. [Non Patent Document 2] describes the efforts of 
the CAPWAP working group. However these efforts do not 
15 consider the problems of accommodating WAPs with 
dissimilar functional capabilities within a single WLAN. 
As such these problems limit the development of the WLAN 
market. 

[0005] 

20 Furthermore, it is expected that future 

deployments of WLANs will feature dynamic wireless 
networks. In such types of deployments, network 

topologies will change during the operational lifecycle 
of the WLAN to enable enhanced applications and services. 

25 WLAN elements in such networks will be provisioned with 



both wired and wireless connectivity to enable dynamic 
topologies. However current assumptions of WLANs (and 
also CAPWAP) only refer to static network topologies. So 
while current WLANs are capable of adjusting to the 
5 dynamic conditions of the wireless medium, they are 
unable to accommodate the effects of dynamic topology 
changes . 

[0006] 

For example, current WLAN systems adjust to 
10 declines in the signal-to-interference ratio (SIR) of 
the wireless medium by increasing the signal 
transmission power. However such minor corrections are 
inadequate to accommodate the variances in latency and 
overhead introduced by changes in WLAN topology. 
15 Furthermore, these variances in latency and overhead 
impede the operation of the CAPWAP split architecture. 
This is because the split architecture is sensitive to 
delays due to the very nature of the distributed 
operations. The redundancies of WLAN and CAPWAP 

20 processing performed at intermediate wireless access 
points (WAP) of a dynamic CAPWAP topology together with 
the corresponding physical overheads are detrimental to 
the CAPWAP split operations. 
[0007] 

25 Given such scenarios, WLAN entities currently 



available from various vendors are incapable of 
interoperation in a single WLAN and are also incapable 
of operation in a dynamic topology WLAN. 
[0008] 

5 These problems refer to static differences between 

WLAN entities as they are results of differences in 
basic design. In addition to these, there are also 
problems related to dynamic differences between WLAN 
entities. 

10 [0009] 

In particular, during the functioning of a WLAN, 
the processing load at a WAP can become substantially 
high even exceeding the processing capacity of the WAP. 
This could be due to increases in the number of 

15 associated mobile terminals (MTs) or due to increases in 
the volume of traffic from the associated MTs. These 
differences in processing load over time constitute a 
dynamic factor as they are dependent on the dynamics of 
the MTs. 

20 [0010] 

These dynamic differences in processing load 
across the WAPs consisting of a WLAN have traditionally 
been addressed by affecting handovers of MTs from their 
associated WAPs where processing load is high, to re- 

25 associate the MTs with other WAPs where processing load 



5 

is relatively low. 
[0011] 

[Patent Document 1] discloses means for addressing 
dynamic differences in the levels of processing load at 
5 WAPs by means of proactive handovers of associated MTs. 
While [Patent Document 1] addresses the problem of 
dynamic differences . in processing loads across WAPs, it 
does so by mandating that MTs associated with one WAP 
also be within the coverage areas of other WAPs so as to 

10 be able to perform handovers and re-associations. If a 
MT is not within the coverage area of one or more other 
assisting WAPs, it is then expected to physically 
displace to such a coverage area in order to relieve the 
first WAP of some processing load. These constraints are 

15 rigid and limit the efficacy of [Patent Document 1] . 
Such limitations are common to all handover-based 
methods . 

[0012] 

[Patent Document 2] presents a method for WAPs to 
20 modify, based on prevailing processing load levels, the 
intervals between the beacon signals that they transmit 
in order to attract or dissuade MT associations. This 
method also involves the constraints of requiring a MT 
to be within the coverage areas of alternate WAPs where 
25 processing load is low or being agreeable to displace 
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towards such areas. 
[0013] 

[Patent Document 3] focuses on proactive MTs that 
make association decisions. However the method is also 
5 limited by the factors described earlier. 
[0014] 

While such methods attempt to solve the problem of 
dynamic differences in processing load, they do so by 
introducing stringent prerequisites and thereby 

10 introduce more problems. Another shortcoming of [Patent 
Document 1] , [Patent Document 2] , [Patent Document 3] 
and other handover-based methods for dealing with 
dynamic differences in WAPs is related to the bulk 
shifting of communication sessions. In practice MTs 

15 maintain a number of communication sessions with the 
WAPs with which they are associated. As a result, it is 
very likely that the communication sessions of only one 
MT or a few MTs constitute a considerable amount of 
processing load at the WAP. If the WAP were to affect 

20 the said MTs to handover and re-associate with another 
WAP, the processing load at the first WAP would be 
reduced, however by adversely affecting the other WAP. 
The other WAP then becomes overloaded and reverses the 
handover to the first WAP. This may continue without 

25 delivering any net gains for the WLAN. This points out 
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that the processing load is not finely distributed by 
methods of handovers. In other words , dynamic 

differences are not finely managed. 

[Non Patent Document 1] Institute of Electrical 
5 and Electronics Engineers Standard 802.11 - 1999 (R2003) 

[Non Patent Document 2] "CAPWAP Problem 

Statement" , draf t-ietf -capwap-problem-statement-02 . txt 

[Patent Document 1] "Method and apparatus for 
facilitating handoff in a wireless local area network" , 
10 US 2003/0035464 Al 

[Patent Document 2] "Dynamically configurable 
beacon intervals for wireless LAN access points" , US 
2003/0163579 Al 

[Patent Document 3] "Method and apparatus for 
15 selecting an access point in a wireless network" , US 
6,522,881 Bl 

DISCLOSURE OF THE INVENTION 
[0015] 

20 In view of the above discussed problems, it is the 

objective of the present invention to provide an 
apparatus and method for negotiations between 
controlling nodes (CNs) and wireless access points 
(WAPs) of a WLAN based on policies that allow for 

25 accommodating static and dynamic differences among the 
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WLAN entities including dynamic changes in WLAN 
topologies within a single WLAN. 
[0016] 

It is another objective of the present invention 
5 to provide a method and policy for negotiations between 
WLAN entities for the purpose of determining selected 
subsets of functional, load or other components to be 
processed by each of said WLAN entities so as to 
accommodate variations in system design, processing load 
10 or network topology. 
[0017] 

It is another objective of the present invention 
to provide an apparatus and method for negotiations 
between WLAN entities based on polices that allow for 
15 accommodating the dynamic differences between them such 
as differences in processing load levels at various WLAN 
entities within a single WLAN . 
[0018] 

It is yet another objective of the present 
20 invention to provide means for accommodating the 
operations of split architecture WLANs in the presence 
of dynamically changing network topologies. 
[0019] 

The disclosed invention relates to wireless local 
2 5 area networks (WLANs ) and particularly to means of 
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addressing the issues of static and dynamic differences 
among WLAN entities. It introduces policies for 

negotiations between WLAN entities for the purpose of 
accommodating these differences. 
5 [0020] 

One aspect of the present invention deals with 
negotiations between controlling nodes (CNs) and 
wireless access points (WAPs) of a WLAN based on 
policies that allow for accommodating static differences 

10 among them. Specifically, it presents means for 

determining a flexible division in WLAN functionality 
between the negotiating entities. The present invention 
first involves classifying the functional capabilities 
of WLAN entities. The entities then determine the 

15 capabilities of other entities followed by negotiations 
between them on how best to divide the functionality 
among them. Further operations of the WLAN entities are 
then based on the determined division of functionality. 
This aspect of the present invention enhances 

20 interoperability for WLAN entities. 
[0021] 

Another aspect of the present invention deals with 
negotiations between WLAN entities based on polices that 
allow for accommodating the dynamic differences between 
25 them. Particularly, it addresses the issue of 



% 
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10 

distributing processing load among WAPs without 
requiring physical displacement of associated mobile 
terminals (MTs) . It involves first determining the need 
to distribute parts of processing load at a WAP. This is 
5 followed by the determination of which parts of 
processing load may be distributed while at the same 
time maintaining existing association relationships 
between MT and WAP. Next, an overloaded WAP enters into 
negotiations with other WAPs in order to determine how 

10 the determined parts of processing load may be 
distributed among them. This aspect of the present 
invention overcomes the limitations of handover-based 
methods for managing dynamic differences between WLAN 
entities . 

15 [0022] 

In its broadest aspect, the present invention 
provides a system for providing service in a WLAN 
whereby a control node negotiates with WAPs and provides 
similar or different complimentary functionality for 

20 each of the WAPs to form a complete functionality 
defined for the WLANs. 
[0023] 

In its preferred form, the present invention 
allows for a controller module for control nodes to 
25 comprise a single or plurality of processing schedules 



11 



composed of sequential lists of descriptors for subsets 
of functional components used for each wireless access 
point . 

[0024] 

5 In another preferred form, the present invention 

provides a method for providing services in a WLAN 
wherein a control node dynamically discovers the 
capability of a WAP by sending a single or plurality of 
messages to a WAP containing a section that emulates the 

10 data unit sent by a mobile terminal, a WAP receiving 
said message processes said section using the same 
procedure for processing data units received from a 
mobile terminal and sends it back to said control node 
in a reply message and said control node obtaining 

15 capabilities information of said WAP by examining the 
processed data units in the reply message. 
[0025] 

In another preferred form, the present invention 
allows a method for providing service in a WLAN that 

20 allows defined WLAN function split between WAPs and one 
or more control nodes wherein a subset of WAPs processes 
the total of their subset of functionality defined for 
the WLAN, a control node provides distinct subsets of 
complementary functionality defined for the WLAN to each 

25 of the subset of WAPs. 
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[0026] 

In yet another preferred form, the present 
invention allows for means for determining a flexible 
division in WLAN functionality between the negotiating 
5 entities. The present invention first involves 

classifying the functional capabilities of WLAN entities. 
The entities then determine the capabilities of other 
entities followed by negotiations between them on how 
best to divide the functionality among them. Further 
10 operations of the WLAN entities are then based on the 
determined division of functionality. 
[0027] 

In another aspect, the present invention provides 
a system for load-balancing in a WLAN without requiring 

15 association handover at a mobile terminal whereby a data 
unit for a mobile terminal is processed with the 
complete WLAN functions by a single of plurality of WAPs 
where each WAP processes the data unit with only a 
subset of complete WLAN functions. 

20 [0028] 

In its preferred form, the present invention 
allows for a method of carrying out load balancing in a 
WLAN without requiring a mobile terminal to change 
association relationship with a WAP wherein the WAP 

25 separates the processing functions provided to the 
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mobile terminal into an association specific part and a 
non-association specific part, the WAP negotiates with 
another WAP to process the non-association specific part 
and establishes a secure tunnel with the another WAP, 
5 the WAP tunnels a data unit from a mobile terminal to 
the another WAP through the tunnel after processing the 
data unit with the association specific part of 
functions and the another WAP receiving the processed 
data unit through the tunnel and processing it with non- 
10 association part of the functions. 
[0029] 

In another preferred form, the present invention 
provides a method for determining the distribution of 
non-association specific functions based on information 
15 comprising the size of the data unit to be processed, 
the expected average time for processing a data unit, 
the overhead time for processing a data unit or a 
weighted sum of said information. 
[0030] 

20 In another aspect, the present invention provides 

a method for accommodating variances in a wireless 
network topology wherein the method comprises the step 
of dynamically adapting the operations logic of at least 
one network entity of the wireless network topology to 

25 alter processing of one or more functional sub- 
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components . 

[0031] 

In its preferred form, the present invention 
allows for a method of accommodating variances in a WLAN 
5 by altering the processing of selected functional sub- 
components at at least one network entity by means of 
bypassing processing of said selected functional sub- 
components . 

[0032] 

10 In its preferred form, the present invention 

allows for a method of accommodating variances in a WLAN 
by altering the processing of selected functional sub- 
components at at least one network entity by means of 
selectively processing said selected functional sub- 

15 components. 

[0033] 

In another preferred form, the present invention 
provides a method for altering local-level functional 
semantics while maintaining system-wide functional 

20 semantics of a wireless network by selectivity 
activating functional sub-components of selected network 
entities such that the sum of activated functional sub- 
components across said wireless network corresponds to 
complete functional sub-components of said wireless 

25 network. 
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[0034] 

In yet another preferred form, the present 
invention provides a method for altering local-level 
functional semantics while maintaining system-wide 
5 functional semantics of a wireless network by means of 
shifting the processing of said activated functional 
sub-components from a first network entity to a second 
network entity. 
[0035] 

10 Based on the aspects and preferred forms of the 

present invention, the problem of incompatibility of 
WAPs of different functional capabilities is solved. The 
present invention also solves the problem of WLAN 
operations in dynamic topology environments. In yet 

15 another aspect, the present invention solves the problem 
of accommodating dissimilar volumes of processing loads 
over time. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 [0036] 

FIG. 1 is a diagram illustrating an operational 
representation of a wireless local area network (WLAN) 
system used to illustrate a first aspect of the 
disclosed invention dealing with policies for 

25 negotiations between WLAN entities, particularly between 
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a controlling node (CN) and wireless access points 
(WAPs) ; 

FIG. 2 is a diagram depicting the general 
operational steps involved in a first aspect of the 
5 present invention dealing with policies for negotiations 
between a CN and WAP; 

FIG. 3 is a diagram showing an integrated WLAN 
entity exemplifying one embodiment of a first aspect of 
the present invention in which the capabilities of a CN 
10 and WAP are integrated into one entity; 

FIG. 4 is a diagram illustrating a simplified 
framework for a second aspect of the present invention 
dealing with policies for negotiations for the purpose 
of accommodating dynamic differences among WLAN entities, 
15 particularly between WAPs; 

FIG. 5 is a diagram depicting the general 
operational steps involved in a second aspect of the 
present invention dealing with policies for negotiations 
for accommodating dynamic differences among WLAN 
20 entities. Specif ically, it deals with processing loads 
at various entities; 

FIG. 6 is a diagram serving to explain the 
reasoning for one embodiment of a second aspect of the 
present invention, wherein the definition of processing 
25 load is taken to be the size of the protocol data unit 
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(PDU) that is received by the WAP from associated MTs; 

FIG. 7 is a diagram illustrating one embodiment of 
a second aspect of the present invention in which a 
central controller performs a supervisory role in the 
5 negotiations for accommodating dynamic differences among 
WLAN entities; 

FIG. 8 is a diagram illustrating one embodiment of 
a first aspect of the present invention in which 
negotiations strategies are applied to enable CAPWAP 
10 split operations in dynamic WLAN topologies; 

FIG. 9 is a diagram exemplifying a particular 
embodiment of a first aspect of the present invention 
relating to IEEE802.il WLAN specifications; and 

FIG. 10 is a diagram depicting a sequence of steps 
15 of a first aspect of the present invention in which 
dynamic WLAN topologies are enabled. 

BEST MODE OF CARRYING OUT THE INVENTION 
[0037] 

20 The disclosed invention of policies for 

negotiations between entities of a wireless local area 
network (WLAN) is described in two major aspects, the 
first focusing on negotiations for accommodating static 
differences among WLAN entities also comprising 

25 accommodating changes in WLAN topologies. While the 
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second aspect illustrates means of dealing with dynamic 
differences, particularly in levels of processing load. 
[0038] 

In the following description, for purpose of 
explanation/ specific numbers, times, structures, and 
other parameters are set forth in order to provide a 
thorough understanding of the present invention. However, 
it will be apparent to anyone skilled in the art that 
the present invention may be practiced without these 
specific details. 

[0039] 

Negotiations for Accommodating Static Differences: 
[0040] 

A WLAN system embodying a first aspect of the 
present invention dealing with accommodating static 
differences among WLAN entities is exemplified in FIG. 1. 
The diagram illustrates a WLAN system 100 comprising a 
controller node (CN) 101, a number of wireless access 
points (WAPs) 105 and 107, a plurality of mobile 
terminals (MTs) 113 and a network backbone 117. For the 
sake of simplicity, the WLAN system 100 is shown with a 
single CN whereas the system embodying the present 
invention may comprise any number of CNs. Also, the 
diagram indicates a direct connection between CN 101 and 
the WAPs 105 and 107. Alternatively there may be a 
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number of intermediate nodes between them. Similarly, 
the connection between CN 101 and the network backbone 
117 may also include a number of intermediate nodes. In 
all such cases, the disclosed invention holds scope. 
5 [0041] 

The CN 101 provides support and control to the 
WAPs 105 and 107 that associate with it. A new WAP in 
the WLAN system must first choose and establish 
association relationships with one or more CNs before it 

10 receives support and control from the one or more CNs . 
As such, WAPs may simultaneously hold more than one 
association relationship with one or more CNs. Similarly, 
the MTs 113 choose and maintain associations with the 
WAPs, which in turn provide them with services. These 

15 services include radio transmission and reception, 
secure transport and mobility. An MT may maintain a 
number of associations with one or more WAPs, however 
FIG. 1 simplifies this with each MT maintaining only one 
association with one WAP. 

20 [0042] 

It can be inferred about the WLAN system 100 that 
the WAPs connect to the network backbone via the CN. 
Alternatives to this include the WAPs connecting to the 
network backbone by other means possibly through other 

25 intermediate nodes. In such cases, the CN will only be 
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responsible for the control and management of the WAPs 
associated with it, while connectivity to an external 
network may be handled by other entities. 
[0043] 

5 FIG. 1 shows the CN 101 capable of performing the 

complete set of WLAN functional operations, as specified 
by some established WLAN standard. It is also capable of 
other control and management functional operations . Each 
functional operation is logically represented by one of 

10 the functional components 115. The operations 

represented by each of the functional components may 
include encryption, decryption, medium access control 
protocol data unit (MAC PDU) processing, authentication, 
association, quality of service (QoS) processing, 

15 Internet Protocol (IP) processing etc. 
[0044] 

Each functional component is represented by a 
functional component code. For the purpose of 

illustration, some of the functional components in FIG. 
20 1 are represented by functional component codes 'a' , 
c b' and 'c' . For example functional component 'a' 
may denote the processing required for a certain type of 
encryption, for example Wi-Fi Protected Access (WPA) or 
Advanced Encryption Standard (AES) , functional component 
25 'b 5 for QoS processing, for example priority handling, 
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while functional component c c' may be that for power 
control during radio transmission and reception. The 
functional components are logical units and may be 
implemented with a single processor using different sets 
5 of instructions and context for different functional 
components. Alternatively, each functional component may 
be implemented by individual processing entities 
possibly in disparate entities. While it is envisaged 
that the actual implementations of the functional 

10 components may vary among manufacturers and their 
implementations, the interfaces linking different 
components will be common or compatible so as to allow 
seamless processing of a control or data unit from one 
WLAN entity to another. 

15 [0045] 

Since the WAPs may be from different manufacturers 
or of different implementations, they may incorporate 
among them varying degrees of WLAN functional components. 
These correspond to the different divisions in 

20 functionality between CNs and WAPs. For example, WAP 105 
is shown to be capable of processing functional 
components 'a' , 'b' and 'c' whereas WAP 107 is only 
capable of processing functional components *b' and 
c c' . The remaining functional components necessary for 

25 their WLAN operations and their control are left to be 
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processed by CN 101. These differences between the WAP 
and CN entities represent the static differences that 
are to be accommodated by each other WLAN entity by 
means of the disclosed method for negotiations. 
5 [0046] 

For the proper operation of the present invention, 
it is necessary for the CNs and WAPs from different 
manufacturers to follow pre-defined naming conventions 
for the functional components that they incorporate and 

10 recognize. This ensures that negotiating entities can 
precisely distinguish which functional components a peer 
entity implements. To this end, the functional component 
codes need to be consistent in representing various 
functional components. This convention however need not 

15 be followed strictly to the letter. For example, the 
convention may present standard descriptors for various 
functional components from which the negotiating 
entities may discern their properties. As an 

illustration, "IEEE 802. Hi" describes an IEEE WLAN 

20 standard pertaining to security functionality. So based 
on such descriptors, negotiating CNs and WAPs may match 
parts or all of the names with other descriptors to 
infer the nature of the functionality components which 
the descriptors represent . 

25 [0047] 
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As mentioned earlier, the interfaces between 
functional components also need to be consistent across 
WLAN entities. This is to ensure that the processing of 
a control or data unit may be performed seamlessly from 
5 one WLAN entity to another. For example, a WAP may 
perform decoding with an appropriate functional 
component and then send the decoded data unit to a CN in 
a form suitable for further processing, say, a form that 
may be readily decrypted by a decryption functional 
10 component at the CN . So although there are different 
functional components in different WLAN entities, the 
interfaces between them are mutually recognizable so as 
to provide seamless processing. 
[0048] 

15 Each WLAN entity is controlled in general by a 

controller entity. Thus, CN controller 103, WAP 

controllers 109 and 111 are responsible for the overall 
operations of CN 101, WAPs 105 and 107, respectively. 
While the WLAN system 100 shows the controllers to be 

20 integral to the WLAN entities, the controllers may also 
be separate entities. As such, they may remain disparate 
for each WLAN entity or combined together for a number 
of WLAN entities. It may be envisaged that specialized 
controllers exist for each type of entity. 

25 [0049] 
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The controllers are particularly responsible for 
establishing processing schedules for each of the 
entities that associate with the entities managed by the 
controllers. Consistent with this, the CN controller 103 
5 maintains processing schedules for WAPs 105 and 107 
whereas the WAP controllers 109 and 111 in turn maintain 
processing schedules for their respectively associated 
MTs 113. 

[0050] 

10 A processing schedule refers to a sequence of 

functional components that are to be processed for 
control and data units received from associated devices 
by the entity that the said controller manages. For 
example, WAP controller 109 for WAP 105 maintains a 

15 processing schedule comprising a sequence of its 
functional components 'a' , 'b' and 'c' . When a 
control or data unit arrives from an associated MT 113, 
WAP 105 performs the processing of functional components 
'a' , *b' and 'c' based on the established processing 

20 schedule. The processing schedule at a WAP may be the 
same for all associated MTs if all the MTs incorporate 
consistent functionality. However if MTs implement 
different degrees of functionality, WAPs may also 
maintain separate processing schedules for processing 

25 the control and data units from different MTs. 
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[0051] 

In one embodiment of this first aspect of the 
present invention, WAP controllers 109 and 111 for WAPs 
105 and 107, respectively, first perform a step 201 in 
5 the figure of discovering CNs - The CNs to be discovered 
may be within the same administrative domain as the WAPs 
or the CNs may belong to different administrative 
domains. This step of discovery may be accomplished 
based on any node discovery protocol or by the 
10 broadcast/multicast/anycast of a specific, mutually 
recognizable message invoking responses from available 
CNs . 

[0052] 

Next the WAP controllers choose which among the 
15 discovered CNs to associate with in a step 203. One 
possible metric for this choice may be the round-trip 
latency between the WAPs and CNs. This metric has the 
advantage of allowing for prompt exchanges of control 
messages between the WLAN entities. Other metrics that 
20 may be used for CN selection include network status, 
congestion, subset of WLAN functions offered by CN, cost 
of using the CN, the vendor of the CN, the 
characteristics of the connection to the CN, link status, 
random selection, cost of using the link, manufacturer 
25 identification and a weighted sum of these metrics. 
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Having chosen a CN 101 with which to associate, WAP 
controllers 109 and 111 then enter an association phase 
with the CN. This phase may include mutual 

authentication, exchanges of security information and 
5 the establishment of communication protocols for further 
exchanges . 

[0053] 

Then, in a step 205, WAP controllers 109 and 111 
enter a negotiation phase with CN controller 103 for the 

10 purpose of establishing means to accommodate the 
possible differences in their respective functional 
capabilities. In particular, the negotiations are to 
establish a division of WLAN functionality that is 
consistent with the capabilities of the negotiating 

15 entities and are optimal for the operation and 
management of the whole WLAN. 
[0054] 

The negotiations may be initiated by either a WAP 
controller or a CN controller as in a step 207. WAP 

20 controllers initiate by sending information regarding 
the functional capabilities of the associated WAPs to 
the chosen CN. This information includes the appropriate 
codes corresponding to the functional components that 
the WAPs are capable of processing and their processing 

25 schedules. A CN controller initiates negotiations by 
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requesting for functional capabilities information from 
the associated WAPs . 
[0055] 

Upon receiving capabilities information from the 
5 associated WAPs and based on established policies, CN 
controller 103 determines an initial division of WLAN 
functionality. This division is then enforced between CN 
101 and the associated WAPs 105 and 107 as in step 209. 
The functionality division specifies which of the 
10 functional components that can be processed by the WAPs 
needs to be active and processed by the WAPs themselves 
and which of them needs to be inactive so that they may 
be processed by the CN. 
[0056] 

15 In one embodiment, the initial division of 

functionality is based on a policy that allows each 
associated WAP to process all the functional components 
that they are capable of. With such a division, only 
those functional . components that an associated WAP 

20 cannot inherently process are left to the CN . Such 
functional components are then included in the 
processing schedule of the CN controller. Since WAPs may 
have dissimilar degrees of functional capabilities, the 
CN controller may be required to establish separate 

25 processing schedules for each associated WAP. As such 
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this embodiment presents a policy which allows for the 
full capabilities of each WAP to be leveraged on. 
However this is achieved at the expense of running 
different processing schedules at the CN controller for 
5 different WAPs. 

[0057] 

In another embodiment, the initial division of 
functionality is based on a policy in which the CN 
controller first determines a subset of functional 

10 components that are common across all associated WAPs. 
The associated WAPs must then process only the 
determined subset of functional components even if they 
are capable of processing other functional components. 
Therefore, the remaining set of functional components 

15 required to be processed for each associated WAP will be 
common to all of them. This common set can then be 
processed by the CN. This embodiment presents a policy 
in which the CN controller may maintain a single 
processing schedule for all associated WAPs. If a new 

20 WAP, incorporating functionality components fewer than 
or incompatible with those specified in the existing 
processing schedule, associates with the CN, the CN 
controller repeats the step of determining the subset of 
functional components that are common across all 

25 currently associated WAPs. It is noted that this step 
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need not be performed if a new WAP involves more 
functionality components than that specified in the 
single, previously established processing schedule. 
[0058] 

5 Alternatively, the association of a new WAP with a 

CN may invoke a grace period, in which two processing 
schedules are maintained simultaneously. The first 
corresponds to the existing processing schedule which 
was established before the association of the new WAP, 

10 while the second corresponds to the processing schedule 
which takes into account the functionality of the newly 
associated WAP. Then data units processed during the 
grace period are done so based on the processing 
schedule that is most appropriate. This embodiment 

15 provides uninterrupted services to existing MTs in the 
event of new WAPs associating with the CN. 
[0059] 

In another embodiment, the initial division of 
functionality is based on a combination of policies, 

20 where a subset of associated WAPs is allowed to process 
all the functional components that they are capable of. 
Another subset of associated WAPs process only a common 
subset of functional components that they are capable of 
processing even if they have greater capabilities. The 

25 CN controller determines the subset of functional 
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components that- are common across all of the subset of 
associated WAPs . The remaining set of functional 
components required to be processed for each associated 
WAP will be performed by the CN . Therefore the remaining 
5 set of functional components will be distinct for each 
of the associated WAPs of one subset of associated WAPs 
and be similar for each of the associated WAPs of the 
other subset of associated WAPs. 
[0060] 

10 Next, having determined an initial division of 

WLAN functionality, the division is then sent to the 
associated WAPs for confirmation as in a step 209. The 
WAP controllers in turn verify that the division is 
feasible and upon verification return a positive 

15 acknowledgement to the CN as in steps 211 and 213. 
[0061] 

Given that some WAPs may implement functional 
components in a non-partitioned manner, for example in a 
hardwire system, such WAPs may not be able to adhere to 

20 the specified initial functionality division. In these 
cases, the WAPs send a negative acknowledgement to the 
CN with an updated processing schedule that indicates 
operational dependencies between their functional 
components as in a step 215. The CN controller then 

25 takes this new processing schedule into account and 
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formulates another functionality division that may be 
compatible with the WAPs. If the new division is 
feasible, the WAPs return a positive acknowledgement and 
if not, the negotiations continue in a similar fashion. 
5 As a last resort, upon a fixed number of unsuccessful 
negotiation exchanges, the CN allows the WAPs to process 
all their functional components. 
[0062] 

During the initial negotiation phase, either CN or 
10 associated WAP may choose to forcibly terminate further 
negotiations based on pre-defined policies and rules 
even before the negotiation phase is complete. These 
policies are enforced by either CN or WAP when it is 
inferred that further negotiations will be moot as in 
15 steps 219 and 221. For example, if the difference at the 
initial division of WLAN functionality is significantly 
dissimilar from the capabilities of a WAP, the WAP may 
choose to terminate negotiations as it may be futile to 
proceed further. Alternatively, if either entity 

20 determines that the other is illegitimate, the 
negotiations may be terminated. Many other policies may 
also be used to enforce termination of negotiations. 
[0063] 

Once a functionality division is acceptable to all 
25 participating WLAN entities, CN controller 103 
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establishes appropriate processing schedules for 
associated WAPs 105 and 107 as in a step 217. These 
schedules define the sequence of functional components 
that are to be processed by CN 101 for control and data 
5 units received from associated WAPs 105 and 107. Then, 
CN controller 103 manages each associated WAP in a 
manner consistent with the processing schedules. 
[0064] 

In one embodiment , WLAN functionality may be 

10 divided into four functional components that may be 
denoted by functional component codes 1, 2, 3 and 4. The 
functional component corresponding to code 1 relates to 
that parts of WLAN functionality concerning the radio 
aspects. This may include radio transmission and 

15 reception, coding, modulation, power control and beacon 
signal control. Such a division combining aspects 
concerning the radio interface will allow for simpler 
design. The code 2 functional component relates to 
security aspects, which may include authentication, 

20 association, encryption and decryption. The basis for 
this division is that processing for security involves 
mathematical computation for which reason they may be 
consolidated and optimized. Then, the functional 

component of code 3 deals with the processing required 

25 for control and data protocol data units (PDUs) . This 
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includes bridging, routing, retransmissions and Internet 
Protocol (IP) layer processing for which specialized 
network processors have been developed. Next, the code 4 
functional component relates to the general control and 
5 management of the WLAN. Quality of Service (QoS) control, 
configurations and policy management are some of the 
aspects of this functional component. This embodiment 
presents simple and practical classification for WLAN 
functionality. Negotiations between various WLAN 

10 entities may then be based on these classifications. The 
classifications may also be used to describe different 
entities. For example, a WAP implementing only radio 
aspects of WLAN may be referred to as a type 1 entity 
which will then require a CN capable of the remaining 

15 functional components 2, 3 and 4. 
[0065] 

In another embodiment of the first aspect, a WAP 
controller need not explicitly send its functional 
capabilities information to a CN controller, however 

20 rather the CN controller infers the capabilities of an 
associated WAP. Such means for automated capabilities 
discovery allows for easier determination of functional 
capabilities without requiring the explicit exchange of 
functional component codes between a CN and associated 

25 WAPs. In this embodiment, a CN controller sends a 
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special command to an associated WAP to which the WAP 
responds by generating a data unit and processing it 
based on its functional components. The emulated data 
unit is then sent to the CN after being processed by the 
5 WAP. The CN controller then infers the functional 
capabilities of the associated WAP based on the received 
emulated data unit. Subsequent operations then follow 
from a step 209 in FIG. 2. This embodiment requires 
associated WAPs to be capable of recognizing and 
10 responding to the special command issued by the CN 
controller . 

[0066] 

An alternate form of the embodiment involves a CN 
controller simulating a data unit as if it was a mobile 

15 terminal and sending the simulated data unit to an 
associated WAP. The destination address of the simulated 
data unit is set to be the CN itself. Upon receiving the 
data unit, the WAP performs its processing based on its 
capabilities and forwards the processed data unit back 

20 to the CN. The CN controller then infers the functional 
capabilities of the associated WAP from the processed 
data unit. After this, the CN controller devises an 
initial division of WLAN functionality and sends this to 
the associated WAP. Subsequent operations then follow 

25 from a step 209 in FIG. 2. 
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[0067] 

In another embodiment of the present invention, a 
single entity that integrates both WLAN operational 
functionality and control and management functionality 
5 is presented. FIG. 3 exemplifies this embodiment in that 
it illustrates such an integrated WLAN entity 301. The 
integrated WLAN entity 301 is capable of both WAP 
operations and CN control and management operations for 
which there are a WAP controller 303 and a CN controller 

10 305, respectively. Each of the WAP and CN functional 
operations is logically represented by one of the 
functional components 307 each denoted by a functional 
component code. These functional components encompass 
WAP operations like radio transmission and reception, in 

15 addition to CN operations like WLAN monitoring and 
configuration management. 
[0068] 

The set of functional components 307 are common to 
both WAP and CN controllers so that the processing 

20 schedule at each controller may include any of the 
functional components. Each controller operates in an 
independent manner with the understanding that the 
complete set of functional components is available for 
it to schedule. As such, during the negotiations phase 

25 between WAP controller 303 and CN controller 305, the 
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WAP controller sends its capabilities information so as 
to include the complete set of codes corresponding to 
all of functional components 307. 
[0069] 

5 Associated with the integrated WLAN entity 301 is 

a number of MTs 309. WLAN system 300 shows the 
associated MTs 309 connecting to a network backbone 311 
via the integrated WLAN entity 301. It is also possible 
for this connection to be made through alternate means 
10 like that through other intermediate nodes. To the 
associated MTs however, there is no difference between 
an ordinary WAP and the integrated WLAN entity. 
[0070] 

Operationally, in this embodiment, the WAP 
15 controller of an integrated WLAN entity first performs a 
discovery of CNs. In essence, the discovery results in 
finding itself as a CN. Upon discovery, an association 
phase follows after which the CN controller and WAP 
controller enter a negotiations phase. Discovery and 
20 association are token operations as both the WAP and CN 
reside within a single entity. 
[0071] 

Next, the WAP controller and CN controller begin 
negotiations in order to determine a suitable division 
25 of functionality between them. The WAP controller first 
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sends information regarding its capabilities to the CN 
controller. This information will include the functional 
component codes corresponding to all the functional 
components available within the integrated WLAN entity 
5 and a processing schedule that involves all the codes. 
In response to the capabilities information and based on 
established policies for functionality divisions, the CN 
controller devises an initial division of functionality 
and sends this to the WAP controller. The initial 

10 division of functionality will be feasible and 
acceptable to the WAP controller since its feasibility 
is based on that of the CN controller which in turn 
determines the division. As a result, the WAP controller 
sends a positive acknowledgement to the CN controller. 

15 Then both controllers establish processing schedules 
according to the accepted division in functionality and 
operate on that basis. This embodiment illustrates how 
the process of negotiations may take place within an 
integrated WLAN entity. As such, the disclosed invention 

20 will be consistent will various designs for these 
entities . 

[0072] 

In another embodiment of the first aspect of the 
present invention, different CNs may incorporate varying 
25 degrees of functionality. As such, a WAP associating 
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with a CN may require the processing of functionality 
which is unavailable both with itself and with the CN 
that it associates. This embodiment serves to address 
such situations by allowing the various CNs in a WLAN to 
5 negotiate among them for the purpose of accommodating 
differences in their functional capabilities. The CNs 
may follow the steps put forth in FIG. 2 to determine 
how the static differences in their functionality may be 
managed. For example, a first CN may only incorporate 2 

10 types of functional components and it may necessitate in 
a third component that it is not capable of, but yet it 
is required for providing services to the WAPs 
associated with it. In such a case, the first CN 
discovers and associates with a second CN in the WLAN 

15 with which it then negotiates. The negotiations are for 
the purpose of dividing functionality among the CNs. As 
a result, the first CN may allow processing of the third 
functional component to be performed by the second CN. 
[0073] 

20 In yet another embodiment of a first aspect of the 

present invention, dynamics changes in WLAN topologies 
is addressed. Fig. 8 illustrates the general aspects of 
a CAPWAP based dynamic WLAN system 800. Here, WLAN 
functions (represented by functional components 1 

25 through 5) are divided between the central controlling 
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node 801 and the set of distributed wireless access 
points, WAP1 803 and WAP2 805. It is emphasized that the 
central controlling node 801 is capable of managing WAPs, 
WAP1 803 and WAP 2 805, of dissimilar capabilities. 
5 [0074] 

The first instance of the topology 807 represents 
a static case of operation. Here, WAP1 803 and WAP2 805 
have fixed connections in the WLAN system 800. Then a 
transition 813 occurs in which the WLAN system 800 

10 transforms into the second instance of the topology 809. 
In this instance, WAP1 803 displaces to an alternate 
location in which it establishes a new connection 815 to 
the controlling node 801 via WAP2 805. The transition 
813 represents a dynamic change and the second instance 

15 809 represents a new WLAN topology in which WAP1 803 
still provides services to its mobile clients 811. At 
the same time, WAP1 803 behaves as another mobile client 
to WAP 2 805. 

[0075] 

20 In the second instance of the topology 809, the 

communication unit 823 exemplifies the communication 
traffic from the mobile clients 811. The communication 
unit 823 is first handled by WAP1 803 (as seen by a step 
817) where all three WLAN functional components and the 

25 CAPWAP control component are processed. It is noted that 
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this step 817 also adds physical overhead in the form of 
a CAPWAP protocol header in addition to the header 
required for transmission to WAP2 805. This is 

illustrated by the 'Cl' sub-field of a step 817. Next, 
5 at WAP2 805, a step 819 is performed where again another 
set of WLAN functional and CAPWAP control components are 
processed. Next, in a step 821, the central controller 
801 performs complementary functions for each of the 
steps 817 and 819. Based the sub-fields of step 821, it 
10 is clear that central controller 801 duplicates some of 
the complementary functions. It is the aim of the 
present invention to avoid this processing duplication 
and transmission overhead. 
[0076] 

15 The operations of the present invention are herein 

described with respect to the steps in Fig. 10. In the 
steps 1001 and 1003, the topology of the wireless 
network is monitored so as to determine any changes in 
the network configuration. Means of realizing these 

20 steps is to analyze the header fields of received 
communication units and compare them to pre-established 
representations of network topology. For instance, in 
the case of IEEE802.il specifications based WLANs, if 
the controlling node 801 receives an Association Request 

25 from WAP2 805 for a mobile client with credentials 
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corresponding to WAP1 803, it is inferred that the 
topology between the controlling node 801 and WAP1 803 
now includes the WAP2 805. Another means of establishing 
topology change is by periodically exchanging 
5 information on neighbouring network entities. A variance 
in these exchanges implies an alternate topology. 
[0077] 

Once a network topology change has been determined, 
the network entity that will accommodate the change, 

10 WAP 2 805, is triggered with an 'Operational 
Associations' signal as in a step 1005. This signal 
comprises preliminary state information regarding the 
network entity affecting the topology change, WAP1 803, 
and the mobile clients 811 managed by said WAP1 803. In 

15 one embodiment based on the IEEE802.il specifications, 
the preliminary state information comprises the number 
of mobile clients 811 managed by WAP1 803, association 
identifications for mobile clients 811 and Source MAC 
addresses of the mobile clients 811. The preliminary 

20. state information may also comprise additional state 
information exemplified by the MAC address of network 
entity effecting topology change, WAP1 803. Next, in a 
step 1007, the network entity accommodating the topology 
change, WAP2 805, is triggered with an 'Operations 

25 Update' signal to adapt its functioning so as to handle 
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the topology change. In one embodiment based on the 

IEEE802.il specifications, the 'Operations Update* 
signal comprises a code value corresponding to an action 
'Forward Frames to Transmission Block' and a code value 
5 corresponding to those 'Data Frame' type for which said 
action is to be taken for. The 'Operations Update' 
signal may also comprise additional parameters 
exemplified by 'Basis Service Set Identification 
(BSSID) ' , 'Source MAC address' or 'Destination MAC 

10 address' . In another embodiment based on the IEEE802.il 
specifications, the 'Operations Update' signal affects 
the Medium Access Control (MAC) management and control 
logic of WAP2 805. Specifically, the logic is altered 
such that communication frames from the mobile clients 

15 811 managed by the network entity effecting the topology 
change (WAP1 803) may now be managed by WAP2 805 without 
going through the normal association and authentication 
phases. In yet another embodiment this logic alteration 
is realized by modifying the ' Filter_MPDU' process of 

20 the 'Reception' block of WAP2 805 so as to direct all 
communication frames received from the mobile clients 
811 to the normal sequence of processing. Alternatively, 
the associations and authentications may be pre- 
established by the controlling node 801. 

25 [0078] 
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After the network entity accommodating the 
topology change, WAP2 805, is updated, an 'Operational 
Associations Request'' signal is triggered at the network 
entity effecting the topology change, WAP1 803, as in a 
5 step 1009. In one embodiment based on the IEEE802.il 
specifications, the 'Operational Associations Request' 
signal comprises code values corresponding to 'Security 
Algorithm Type' , 'Security Key' , 'Session 

Identification' or 'Association Identification' 

10 parameters for which corresponding information values 
are requested. The request signal is to obtain specific 
state information regarding WAP1 803 and the mobile 
clients 811 which it manages. This state information is 
then made aware to WAP2 805 by an 'Operational 

15 Associations Update' signal, as in a step 1011, in 
preparation for future functioning. In one embodiment 
based on the IEEE802.il specifications, the 'Operational 
Associations Update' signal comprises information values 
corresponding to 'Security Algorithm Type' , 'Security 

20 Key' , 'Session Identification' or 'Association 
Identification' parameters . 
[0079] 

Next, in a step 1013, an 'Operations Update' 
signal is triggered to the network entity effecting the 
25 topology change, WAP1 803, so as to alter its 
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functioning logic. In particular the signal directs WAP1 
803 to bypass certain processing that may be duplicated 
at WAP2 805 (so that WAP 2 805 neglects the processing at 
WAP1 803, and performs the processing at only WAP 2 805) . 
5 The intent of the step 1013 is to prevent duplication of 
WLAN and CAPWAP processing at both WAP1 803 and WAP2 805. 
Furthermore, bypassing of processing at WAP1 803 reduces 
the physical overhead for transmissions over the newly 
established wireless connection 815 and thereby reduces 
10 transmission delays. These two aspects combined ensure 
that the timing constraints between WAP1 803 and 
controlling node 801 are maintained according to the 
initial topology instance. 
[0080] 

15 In one embodiment based on the IEEE802.il 

specifications and CAPWAP framework, Operational 
Association state information is exchanged between the 
network entities accommodating topology changes and 
network entities effecting topology changes via the 

20 central controlling node. 
[0081] 

In an alternative to the above described 
embodiment for exchanging Operational Association state 
information, said exchange is accomplished between the 
25 network entities accommodating topology changes and 
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network entities effecting topology changes without 
establishing explicit operational associations between 
them. The network entity effecting the topology change, 
WAP1 803, is instructed to use a specific 'Frame Type' 
5 code for communication frames containing state 
information. Next, an 'Operations Update' signal is 
triggered to the network entity accommodating the 
topology change, WAP2 805, so as to enable it to handle 
communication frames with the specific 'Frame Type' 

10 code in alternate means. Alternatively, specific 

'Subtype' , 'Duration/ID' codes are used. Specifically, 
the alternate means comprises de-capsulation of payload 
of said communication frames and using the payload as 
state information. In one case of the embodiment, the 

15 controlling node 801 governs the various trigger signals. 
[0082] 

In the dynamic CAPWAP framework, the network 
entity effecting topology change, WAP1 803, communicates 
with the controlling node 801 via the network entity 
20 accommodating topology change, WAP2 805. 
[0083] 

In steps 1007 and 1013, the local-level of WLAN 
and CAPWAP functional semantics (wherein functional 
semantics corresponds to the set and sequence of 
25 processing required for WLAN operation) are broken such 
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that selected sub-components of said processing are 
bypassed at selected network entities, the network 
entities accommodating topology changes and the network 
entities effecting topology changes. However, with the 
5 combined steps of 1000 the present invention achieves 
system-wide semantics of WLAN and CAPWAP functional 
processing by dividing selected processing sub- 
components among the controlling node 801, WAP1 803 and 
WAP2 805. So the steps of 1000 selectively activate 

10 various processing sub-components and by doing so, 
achieve system-wide functional semantics. It will be 
clear to those skilled in the art that the steps put 
forth in 1000 may be combined, separated or generally 
altered for the purposes of optimization, implementation 

15 or any other aim without deviating from the essence of 
the present invention. As such the scope of the present 
invention is not limited to the specific steps of 1000. 
[0084] 

Fig. 9 illustrates an embodiment of the present 
20 invention operating on steps 1000 for the WAP1 901. The 
logical operations of WAP1 901 are based on the 
IEEE802.il WLAN specifications but may readily exemplify 
other wireless specifications also. WAP1 901 manages 
mobile clients 903 by processing various data (D) , 
25 management (M) and control (C) frames in addition to 
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general operations. The processing logically comprises 
'Reception' 905, 'WAP Processes' 909 and 

'Transmission' 911 blocks. The 'Reception' block 905 
further comprises a ' Filter_MPDU' process whose logic 
5 is based on a filter 907. The filter 907 is used to 
compare arriving frames based on various metrics and 
appropriately handle them. 
[0085] 

In response to the 'Operations Update' signal of 
10 step 1013, the filter logic is updated to include the 
changes of filter logic update 913. In the embodiment, 
data frames are directly sent to the 'Transmission' 
block 911 completely bypassing the 'WAP Processes' 909. 
As a result, processing time for the majority data 
15 frames is drastically reduced at WAP1 901. These data 
frames are then handled by WAP2 915 whose operations 
were updated according to a step 1007. Since management 
and control frames directly relate to the connection 
between WAP1 901 and the mobile clients 903, they are 
20 processed locally at WAP1 901. So the present invention 
selectively activates processing by affecting the 
reception logic of WAP1 901. 
[0086] 

In one embodiment, the network entities 
25 accommodating topology changes and the network entities 
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effecting topology changes operate according to 
dissimilar wireless specifications. With respect to Fig* 
8, WAP1 803 operates according to IEEE802.il 
specifications and WAP2 805 operates according to 
IEEE802.16. The principles of adapting local-level 
functional semantics while maintaining system-wide 
functional semantics are then applied to the network 
entities operating according to dissimilar wireless 
specifications. It is noted that the dissimilarity in 
operations may comprise Bluetooth connectivity, 
IEEE802.20, cellular telephony or any other wireless 
specifications . 
[0087] 

There are a number, of scenarios and applications 
in which the present invention for dynamic WLAN 
topologies will be incorporated. For example, future 
home networks will be capable of extending coverage 
areas in impromptu manners. Transportation systems will 
incorporate transmission and reception components so 
that the network topology changes with each passing stop, 
station or seaport. Manufacturing facilities will be 
provisioned with communication networks providing 
connectivity to diverse locations at various time 
instances. The present invention described insofar may 
be embodied in these scenarios to address the problems 
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of latency and overhead in dynamic topology environments. 
[0088] 

The embodiments of this first aspect of the 
present invention described insofar illustrate policies 
5 with which WLAN entities may negotiate with each other 
in order to accommodate the varying degrees of static 
differences that each such entity * incorporates. 
Additionally, the embodiments illustrate the application 
of the first aspect of the present invention wherein 

10 local-level of functional semantics are broken so as to 
enable dynamic changes in WLAN topologies in which 
system-wide functional semantics are maintained. They 
describe how WAPs incorporating varying degrees of WLAN 
functionality may be integrally managed by a controlling 

15 node. The disclosed method for negotiations provides for 
flexibility in deploying WLANs with entities from 
different manufacturers or of different implementations. 
While prior arts focus on mandating proprietary means of 
dividing functionality among WLAN entities, the present 

20 invention serves to accommodate entities of different 
degrees of functionality. As a result, the division of 
WLAN functionality between controlling nodes and 
wireless access points may be achieved in a flexible 
manner . 

25 [0089] 
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Negotiations for Accommodating Dynamic 

Differences : 
[0090] 

This aspect of the present invention describes 
5 policies with which WLAN entities embodying the 
disclosed invention may negotiate with each other for 
the purpose of accommodating dynamic differences among 
them. It is exemplified by using the varying levels of 
processing load at different WLAN entities particularly 
10 WAPs.' 

[0091] 

A simplified representation of a WLAN system 400 
embodying this aspect of the present invention is 
depicted in FIG. 4. It shows WAPs 401 and 403 that are 

15 capable of providing services and performing related 
processing for a number of associated MTs. The WAPs and 
MTs may maintain a number of associations with each 
other. However for reasons of simplicity , the WLAN 
system 400 only shows one association with WAP 401 for 

20 the single MT 405. This MT 405 is associated with and 
receives services from WAP 401 over a wireless 
connection 427. Also the WAPs 401 and 403 are shown to 
be connected to a network backbone 407, through which 
they can communicate with other networks and with each 

25 other, either directly or via intermediate switching or 
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routing devices. The WAPs may also connect to the 
network backbone or with each other through a number of 
intermediate nodes . 
[0092] 

5 During the operation of WLAN system 400, the 

processing loads at the WAPs may vary due to the dynamic 
nature of communication. For example, a number of new 
MTs may choose to associate with a WAP thereby 
necessitating in additional processing at the WAP. 

10 Another example is of a MT choosing to be involved in 
additional numbers of communication sessions again 
resulting in extra processing for the WAP with which it 
is associated. Consequently, the processing load at 
various WAPs in the WLAN system will vary over time. It 

15 is this dynamism that the disclosed invention addresses 
by requiring WAPs to negotiate with each other for the 
purpose of distributing processing load from a heavily 
loaded WAP to a relatively lightly loaded WAP while 
maintaining existing association relationships with 

20 their MTs. 

[0093] 

From FIG. 4, WAPs 401 and 403 provide services to 
associated MTs by performing some type of processing on 
their behalf. The processing may be logically divided by 
25 lines 419 and 421 in WAPs 401 and 403, respectively, as 
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being association-specific (ASP) and non-association- 
specific (nASP) processing. ASP processing 411 and 413 
involve those that are directly dependent on the 
association between MTs and WAPs. Such processing 
5 requires interaction with the wireless interface between 
a WAP and an associated MT . Examples of ASP processing 
include transmission and reception of data units, power 
control, coding and modulation. 
[0094] 

10 nASP processing 415 and 417 refer to processing 

that are not directly dependent on the wireless aspects 
of a connection between WAPs 401 and 403 and associated 
MT 405. Examples of nASP processing include bridging, 
filtering, protocol data unit (PDU) processing and PDU 

15 delivery. 

[0095] 

WAP controllers 423 and 425 manage and control the 
overall processing at WAPs 401 and 403, respectively. 
[0096] 

20 The operations involved with this aspect of the 

present invention are described with reference to FIG. 5. 
The WAP controller in each of the WAPs in a WLAN system 
embodying the present invention performs a step 501 of 
monitoring the nASP processing load at the WAP. This 

25 includes monitoring the nASP processing load for each of 
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the communication sessions for all the associated MTs. 
Examples of how processing load may be monitored include 
means for monitoring the processor usage or duration of 
processor activity for a communication session and then 
5 aggregating this for all communication sessions. Another 
example is means for monitoring the amount of memory 
usage for communication sessions. Similarly, a number of 
other factors may be monitored, either independently or 
in any combination, to monitor the overall nASP 
10 processing load at a WAP. Furthermore, other means of 
monitoring may also be used. 
[0097] 

In one embodiment of the present invention, a WAP 
controller 423 for a WAP 401 derives a resource 
15 characteristic for the WAP based on the various factors 
of nASP processing load that are monitored for each 
communication session of the associated MTs. The 
resource characteristic is a representation of the 
resources or processing load required for providing 
20 services to a communication session. 
[0098] 

Next, the resource characteristics of all 
communication sessions for all associated MTs are 
combined to obtain an aggregate nASP load factor for WAP 
25 401. The aggregate nASP load factor is then compared to 
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a nASP load threshold, in a step 503, to determine 
impending nASP processing overload conditions that may 
not be manageable by WAP 401. If the aggregate nASP load 
factor is determined to be manageable at WAP 401, the 
5 monitoring of a step 501 is repeated. 
[0099] 

If, however, impending nASP processing overload 
conditions are determined, the WAP controller 423 then 
determines in a step 505, which parts of the nASP 

10 processing load at WAP 401 may be distributed to other 
WAPs of the WLAN system with the aim of reducing overall 
processing load at WAP 401 while at the same time 
maintaining existing association relationships with 
associated MTs, such as that with MT 405. Such a 

15 mechanism is unique from traditional methods of 
distributing processing load which mandate handovers 
that may necessitate in a MT physically displacing to a 
coverage area of another WAP. The step 505 is based on 
the resource characteristics of the communication 

20 sessions of MTs associated with WAP 401. For example, a 
WAP controller may choose to distribute those parts of 
processing load with the greatest resource 
characteristics or those with the least resource 
characteristics. This choice may also be based on other 

25 factors such as the expectation of future changes in 
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resource characteristics . 
[0100] 

Next, the negotiations phase begins between a 
first WAP controller and other WAP controllers. This 
5 phase involves determining which of the other WAPs are 
agreeable to accommodate the dynamic differences in 
processing loads by taking over some parts of the nASP 
processing load of the overloaded first WAP. In a first 
stage of negotiations , the WAP controller 423 executes a 

10 step 507 of sending solicitation messages to other WAPs 
of the WLAN system. The solicitation messages include 
the resource characteristics of those parts of nASP 
processing load of WAP 401 that have been determined by 
the WAP controller to be distributed to other WAPs. 

15 [0101] 

WAP controllers receiving the solicitation message 
determine if they are capable of accommodating the 
additional processing load as specified in the message. 
These controllers then respond to the WAP controller 

20 initiating the solicitation by either accepting to take 
over the complete specified load or accepting to handle 
partial amounts of the load. The initiating WAP 
controller then uses the responses to determine which of 
the other WAPs are agreeable and to which extent 

25 agreeable, to receiving parts of the nASP processing 
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load that it initially specified. The negotiations may 
also extend beyond the initial solicitation message if 
.such a need is inferred to exist by the initiating WAP 
controller. As such, a step 507 is used to determine 
5 which of the other WAPs in the WLAN system are agreeable 
to receiving and perform processing of parts of nASP 
processing load of WAP 401 in order to reduce the 
processing load at WAP 401. 
[0102] 

10 Next, in a step 509, WAP controller 423, of the 

overloaded or soon to be overloaded WAP, establishes a 
tunnel connection 409, between WAP 401 and the WAPs 
determined in a step 507 to be agreeable to receiving 
and processing the determined parts of nASP processing 

15 load of WAP 401. FIG. 4 illustrates one of the agreeable 
WAPs to be WAP 4 03. Relevant context information 
required for processing of the determined parts of nASP 
processing load is then transmitted over the established 
tunnel connection to the agreeable WAPs. Then, in a step 

20 511, WAP controller 423 distributes the determined parts 
of the ASP processing load of WAP 4 01 to the agreeable 
WAPs over the tunnel connection. In doing so, WAP 
controller 423 reduces the overall processing load at 
WAP 401. All this is achieved while maintaining existing 

25 associations with associated MTs and in a fine grained 
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manner so as not to overwhelm the agreeable WAPs. 
[0103] 

This embodiment illustrates the efficacy of this 
aspect of the present invention in distributing 
5 processing load without the limitations of existing 
handover-based methods. As such, there are no 

constraints as to the geographic position or willingness 
to displace for the associated MTs. 
[0104] 

10 In another embodiment of this aspect of the 

present invention, an overloaded WAP simply relays the 
processing load required for communication sessions of 
associated MTs to other agreeable WAPs. This relay may 
be over wireless,, wired or a combination of both types 

15 of links. Relevant context information may also be 
relayed so as to facilitate the processing of the 
relayed processing load. 
[0105] 

In one embodiment, the tunnel connection between 
20 two WAPs is established over a direct link between WAPs. 
This direct link may be wireless and similar to the link 
between WAPs and MTs in which case the WAPs determine a 
radio channel alternate from the channel used for 
communication with associated MTs and use this to 
25 exchange relevant context information and determined 
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parts of nASP processing load- Alternatively, the link 
between two WAPs can be wired and directly connected. 
With this embodiment, the tunnel connection need not 
traverse the network backbone but rather can be 
5 established directly. 
[0106] 

In another embodiment of the present invention, 
nASP processing load is defined as the processing 
required for security algorithms used for the encryption 

10 and decryption of MAC PDUs that are transmitted to and 
received from associated MTs. Processing of security 
algorithms is a type of non-association-specific 
processing which is computationally intensive due to the 
complex characteristic. As such, a significant increase 

15 in the number of associated MTs or in the volume of 
traffic to and from associated MTs will in turn lead to 
a corresponding increase in the processing of the 
security algorithms. In this embodiment, WAPs and 
associated MTs encrypt their respective transmissions 

20 over the wireless connection based on an established 
security algorithm. Upon receipt of transmissions, the 
WAPs and MTs perform decryption processing based on the 
same established security algorithm. 
[0107] 

25 When the nASP processing load for encryption and 
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decryption becomes significant, as measured by its 
resource characteristic exceeding a nASP load threshold, 
a WAP controller 423 of WAP 401 sends a solicitation 
message to determine which of other WAPs in the WLAN 
5 system are agreeable to receiving and processing parts 
of nASP processing load corresponding to the security 
algorithms used for transmissions between WAP 401 and MT 
405. If WAP 403 is agreeable to processing the nASP 
processing load, its WAP controller 425 responds to the 

10 solicitation message. Upon receipt of the response to 
the solicitation message, WAP controller 423 establishes 
a tunnel connection 409 to WAP 403 and then sends 
relevant security keys and context information to WAP 
403 via the established tunnel connection. 

15 [0108] 

Next, upon establishment of the tunnel connection 
409 and exchange of the security keys and context 
information, WAP controller 423 sends to WAP 403 
encrypted MAC PDUs received from associated MT 405. WAP 

20 controller 423 also sends to WAP 403, MAC PDUs that are 
to be encrypted before transmission to the associated MT 
405. WAP 403 then processes the nASP processing load for 
encryption of MAC PDUs and sends the encrypted MAC PDUs 
to WAP 401 via the tunnel connection. Having received 

25 the encrypted MAC PDUs, WAP 401 then transmits them to 
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the associated MTs . In this embodiment, the 

computationally intensive processing of security 
algorithms is distributed across WAPs so as to lower the 
processing load at a WAP . This is performed without 
5 affecting re-associations of MTs and as such this method 
is not limited by the shortcomings of handover-based 
methods . 

[0109] 

In another embodiment, a WAP controller 

10 distributes the nASP processing load corresponding to 
those security algorithms that cannot be processed by 
the WAP due to reasons of unf amiliarity of the said 
security algorithms while at the same time maintaining 
association relationships with associated MTs. Given the 

15 growing numbers of MTs and other devices in which WLAN 
capabilities are incorporated, there may be many 
security features implemented in such MTs and devices, 
all of which not being recognizable by all WAPs with 
which associations are sought. As such this embodiment 

20 allows a WAP to maintain associations with MTs and other 
devices even if some of the required processing are not 
possible at the said WAP. The embodiment is described 
using an uncommon security algorithm as example; however 
it is valid for any other type of processing that is 

2 5 uncommon between WAP and MT . 
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[0110] 

During an association of a MT with a WAP, a 
security algorithm that is knowledgeable to both 
entities is negotiated upon for securing transmissions 
5 over the wireless connection between the two entities. 
Traditionally, if the WAP is not knowledgeable of any of 
the security algorithms used by the MT, the MT cannot be 
associated with the said WAP. The here forth described 
embodiment of the present invention transcends this 
10 limitation and permits MT3 to associate with a WAP even 
if the WAP is not knowledgeable of any of the security 
algorithms used by the MTs. 
[0111] 

In this embodiment, a WAP controller 423 permits a 
15 MT 405 to associate with WAP 401 even though there are 
no common security algorithms that both WAP 401 and MT 
405 are knowledgeable of. During the association phase, 
WAP controller 423 sends a solicitation message to other 
WAPs in the WLAN system 400 to determine which WAPs are 
20 knowledgeable of and agreeable to processing any of the 
security algorithms familiar to MT 405. If WAP 403 is 
knowledgeable of and agreeable to processing any of the 
security algorithms familiar to MT 405, WAP controller 
425 responds to the solicitation message from WAP 
25 controller 423 with a chosen security algorithm. Upon 
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receipt of the response to solicitation message, WAP 
controller 423 then establishes a tunnel connection 409 
with WAP 403. WAP controller 423 next sends relevant 
security keys and context information to WAP 403 via the 
5 established tunnel connection 409. The chosen security 
algorithm is then intimated to MT 405 and it is 
associated with WAP 401. 
[0112] 

Upon establishment of the tunnel connection 4 09 

10 and exchange of security keys and context information, 
WAP controller 423 sends to WAP 403, MAC PDUs received 
from MT 405 associated with WAP 401, that have been 
encrypted based on the chosen security algorithm. WAP 
403 receives the encrypted MAC PDUs via the tunnel 

15 connection and decrypts them based on chosen security 
algorithm and established security keys and context 
information. WAP controller 423 also sends to WAP 403, 
MAC PDUs that are to be encrypted before transmission to 
the associated MT 405. In this case, WAP 403 receives 

20 MAC PDUs via the tunnel connection 409, encrypts them 
based on chosen security algorithm and sends the 
encrypted MAC PDUs back to WAP 401. WAP 401 then 
transmits the encrypted MAC PDUs to the associated MT 
405. In this embodiment, the lack of knowledge about a 

25 security algorithm does not limit a WAP from allowing a 
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MT to associate with it. As such it provides greater 
flexibility in providing services to a great number of 
MTs with different processing requirements. 
[0113] 

5 Another embodiment of the present invention 

relates to the size of PDUs processed by WAPs. Studies 
in processor scheduling have shown that processing large 
PDUs before small PDUs leads to greater average 
processing time as compared to cases where small PDUs 

10 are processed before large PDUs. FIG. 6 illustrates this 
through example. In a first case, it shows two 

processing schedules 601 and 603 for processors 613 and 
615, respectively. The scheduling order 605 and 607 
denote the relative order in which PDUs A, B, C and D 

15 are processed. 609 and 611 denote the processing time, 
in arbitrary time units (tu) , required for processing 
each of the PDUs. 
[0114] 

In schedule 601, large PDUs A and B are processed 
20 before small PDUs C and D. The average processing time 
for the PDUs is 21.25 tu, while it is only 16.25 tu for 
the PDUs in schedule 603 where small PDUs C and D are 
processed before large PDUs A and B. Clearly schedule 
603, in which small PDUs are processed before large PDUs, 
25 leads to significant reductions in average processing 
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time . 

[0115] 

In a second case, the aspect of processing 
overhead for processor scheduling is considered. The 
5 processing of each PDU requires some processing overhead 
which includes memory access time and context transfer 
time. The overhead is generally independent of the size 
of the PDU as it is required before the actual 
processing. FIG. 6 depicts a schedule 617 for small PDUs 

10 alone in which processing overhead time and actual 
processing time is shown by 621 and 625, respectively. 
Processing overhead time 623 and processing time 627 is 
for large PDUs in schedule 619. From this, it is seen 
that the processing overhead takes up 50% of total time 

15 in a schedule 617 whereas overhead constitutes only 
33 1 / 3 % in a schedule 619. This illustrates how 

processing only small PDUs can lead to a processor 
handling more overhead than when a processor handles 
large PDUs. 

20 [0116] 

In an embodiment of the present invention related 
to the size of PDUs, the nASP processing load is defined 
as the size of PDUs handled by a WAP. A WAP controller 
423 of WAP 401 monitors the size of PDUs received over a 

25 wireless connection 427 from an associated MT 405. When 
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WAP controller 423 determines that WAP 401 is processing 
any of the previous described cases, the controller 
determines a processing schedule for a subset of the 
monitored received PDUs. The aim of the processing 
5 schedule is to optimize average processing time and 
processing overhead time at WAP 401. 
[0117] 

Next, WAP controller 423 derives a resource 
characteristic for the PDUs that may be distributed to 

10 other agreeable WAPs for processing. As such, the 
resource characteristic represents the processing load 
required for processing PDUs other than those that are 
processed by the WAP 401 itself. The resource 

characteristic is then sent to other WAPs of the WLAN 

15 system 400 as part of a solicitation message to 
determine WAPs agreeable to processing the PDUs 
described in the message. 
[0118] 

If WAP 403 is agreeable to the nASP processing of 
20 PDUs described in the solicitation message, WAP 
controller 425 responds accordingly. A WAP in the WLAN 
system will be agreeable to processing PDUs from another 
WAP when processing such PDUs would allow it to optimize 
its own average processing time and processing overhead 
25 time. Upon receipt of the response, WAP controller 423 
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then establishes a tunnel connection 409 with WAP 403 
and sends relevant context information to WAP 403 via 
the established tunnel connection. 
[0119] 

5 Having established the tunnel connection and 

exchanged relevant context information, WAP controller 
423 sends to WAP 403, PDUs described by the previously 
sent resource characteristic with the aim of optimizing 
average processing time and processing overhead time at 
10 WAP 401. So with this embodiment, the nASP processing of 
PDUs of different sizes may be distributed in a manner 
so as to optimize processing while at the same time 
maintaining association relationships between WAPs and 
MTs. 

15 [0120] 

In another embodiment, a WAP controller 
distributes the nASP processing load based on 
information comprising the size of the data unit to be 
processed, the expected average time for processing a 
20 data unit, the overhead time for processing a data unit 
and a weighted sum of said information. 
[0121] 

Another embodiment of the disclosed method 
concerns the distribution of processing of ISO-OSI layer 
25 3 and layers above layer 3 from a first WAP to other 
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WAPs while maintaining association relations between the 
first WAP and MTs associated with it. Many WAPs are 
currently capable of processing up to ISO-OSI layer 2, 
however there are vendors manufacturing WAPs capable of 
5 ISO-OSI layer 3 processing. This embodiment refers to 
such devices and other similar WAPs. Processing for ISO- 
OSI layer 3 and layers above layer 3 includes quality of 
service (QoS) provisioning, routing and scheduling. In 
this embodiment, nASP processing load is defined as the 
10 processing concerning ISO-OSI layer 3 and layers above 
layer 3. 

[0122] 

In this embodiment, a WAP controller 423 for WAP 
401 derives a resource characteristic for the processing 

15 of ISO-OSI layer 3 and layers above 3 based on the 
factors of nASP processing load monitored for each of 
the communication sessions between WAP 401 and 
associated MT 405. The resource characteristics of all 
communication sessions are then combined to derive an 

20 aggregate nASP load factor for WAP 401 which is then 
compared to a nASP load threshold to determine impending 
nASP processing overload conditions. 
[0123] 

If impending nASP processing overload conditions 
25 are determined, WAP controller 423 then determines parts 
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of nASP processing load of ISO-OSI layer 3 and layers 
above 3 that may be distributed to other WAPs in the 
WLAN system with the aim of reducing overall processing 
load at WAP 401. Next, WAP controller 423 sends a 
5 solicitation message, comprising resource 

characteristics of the determined parts of nASP 
processing load of ISO-OSI layer 3 and layers above 3, 
to determine which other WAPs are agreeable to receiving 
and performing processing of the parts of nASP 
' 10 processing load on behalf of WAP 401. 
[0124] 

If WAP 403 is agreeable to processing the parts of 
nASP processing load based on the solicitation message, 
WAP controller 423 sends a positive response to WAP 401. 

15 Upon receiving the response, WAP controller 423 
establishes a tunnel connection 409 between WAP 401 and 
WAP 403 after which relevant context information 
required for processing of parts of nASP processing load 
of ISO-OSI layer 3 and layers above 3 is transmitted 

20 over tunnel connection to WAP 403. Then WAP controller 
423 sends the determined parts of nASP processing load 
to WAP 403 with the aim of reducing nASP processing load 
at WAP 401 by distributing parts of processing load to 
other WAPs while maintaining existing association 

25 relations between WAPs and MTs. 
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[0125] 

In yet another embodiment of the aspect of the 
present invention dealing with negotiations for 
accommodating dynamic differences among WLAN entities, a 
5 central controller entity takes part in the negotiations. 
Broadly, the central controller entity coordinates how 
the dynamic differences are to be managed among 
participating WLAN entities. One particular embodiment 
involves the central controller coordinating the 
10 distribution of nASP processing load across the WAPs 
under its purview. 
[0126] 

This is described with reference to FIG. 7 which 
illustrates a central controller 729 that is capable of 

15 monitoring the nASP processing loads at WAPs 701 and 703. 
When the nASP processing load at WAP 701 exceeds a nASP 
processing load threshold, the central controller sends 
a solicitation message to other WAPs in the WLAN system 
requesting assistance for the processing of parts of 

20 processing load of WAP 701. This begins the negotiations 
phase between the central controller 729 and other WAPs 
in the WLAN system 700. The solicitation message 
includes descriptors of the parts of processing load at 
WAP 701 to be distributed to other WAPs with the aim of 

25 reducing overall processing load at WAP 701. 
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[0127] 

If WAP 703 is agreeable to assist with the 
processing for WAP 701, a WAP controller 725 responds to 
the solicitation message. The central controller 729 
5 then intimates WAP 701 about the acceptance, after which 
WAP 701 establishes a tunnel connection 709 with WAP 703. 
It then sends WAP 703 relevant context information 
followed by the parts of processing load as specified in 
the solicitation message. Alternatively, WAP 701 may 

10 send the context information and parts of processing 
load to the central controller 729 which then forwards 
this to the agreeable WAPs like WAP 703. So with this 
embodiment, processing load is distributed across WAPs 
of a WLAN with a central controller coordinating the 

15 distribution. 

[0128] 

In another embodiment, the central controller 
receives regular information from WAP controllers of the 
WAPs under its purview regarding their nASP processing 

20 loads. As such, the WAP controllers themselves determine 
overload conditions and the necessity to distribute 
parts or all of nASP processing load to other WAPs or 
other WLAN entities. The negotiations phase in this 
embodiment is thus initiated by the WAP controllers and 

25 then further pursued between the central controller and 
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other WAPs. 

[0129] 

The embodiments presented so far exhibit how 
negotiations between various WLAN entities based on the 
5 disclosed policies which may be used to accommodate the 
dynamic differences among them. In particular, they 
describe how processing load may be classified as being 
association-specific and non-association- specific . They 
also illustrate how parts of nASP processing load may be 

10 distributed to other WAPs of the WLAN system for the 
purpose of reducing overall processing load at a first 
WAP. The disclosed invention is unique in that it 
permits the distribution of processing load while 
maintaining existing association relationships between 

15 WAPs and MTs . As such, the disclosed method for 
accommodating dynamic differences does not necessitate 
in the physical displacement of any WLAN entity which is 
unlike existing methods. This innovation is therefore 
more flexible than handover-based methods for 

20 distributing processing load. It also transcends the 
limitations of such schemes. 
[0130] 

The various aspects of the disclosure presented 
insofar illustrate the novelty of the method for 
25 negotiations in accommodating static and dynamic 
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differences among WLAN entities. Whereas, extant methods 
focus on hard divisions in functionality among WLAN 
entities, the present invention presents alternate means 
where functionality divisions may be made in flexible 
5 manners. Also, while existing methods require re- 
associations and the consequent geographical and 
physical limitations of handovers, this innovation puts 
forth ways of dealing with imbalances in processing load 
without the constraints of handover-based methods. 

10 [0131] 

It will be clear to anyone skilled in the related 
art that the disclosed invention may take the form of 
numerous other embodiments with numerous other policies 
for the negotiations and handling of differences among 

15 WLAN entities without deviating from the essence and 
scope of this disclosure. As such the present invention 
will be applicable in all such embodiments and practices. 

INDUSTRIAL APPLICABILITY 

20 [0132] 

The present invention has the advantage of 
accommodating differences among WLAN entities. The 
present invention, thus, can be applied to the technical 
field of wireless local area networks and in particular 

25 to the technical field of a wireless local area network 



heterogeneous environments . 



